Travelling between source and destination locations may use information, such as, for example, route to the destination and travel time. Travelling may also use information related to landmarks or points of interest along a route, such as, for example, restaurants, fuel stations, monuments, sights of interest, and location of a friend's home. Information such as sights of interest to a particular user and location of a friend's home may not generally be captured in existing map or navigation systems, for example, due to limitations in data storage, management and efficient retrieval capabilities of travel related systems. Further, if multiple travelers are involved, travelling may use information related to pick-up time for such travelers, location and timing of areas of pick-up and estimated arrival time at such pick-up areas.
Known travel related systems provide navigation based on static data and updates by instant messaging (IM) or short message service (SMS). Such systems may use algorithms based on shortest path, highway use or mode of transport, which rely on static data. Such systems however may not leverage information based on user experiences, or information which changes dynamically as a user continues on a trip. Hence, the state of any given system user may not be maintained.
The foregoing features of travel related systems may be based on limitations in data storage, management and retrieval capabilities of such systems. For example, travel related systems may use relational databases to store, manage and retrieve information. However, relational databases have limited capabilities for handling large sets of unstructured data. Relational databases also have limited capabilities for handling significant data growth over a short time-period and a high rate of concurrent access.
For example, a user of a travel related system using a relational database may request landmark, reviews and images for a point of interest. The relational database may normalize the data related to the point of interest, but would require joins for each component (e.g., landmark, reviews or images) of the request. For any additional components (e.g., ratings per review) of a request, the query would require additional joins. Thus, each component of a query would significantly increase the size of data for a search. For example, if a trip includes nc comments, ni images, nl landmarks, and nr reviews, the relational database including, for example, nt trips, would include at least nt*(nc+ni+nl+nr) records. For a database of millions of trips, the number of overall records would thus be based, for example, on the number of trips times the related comments, images, landmarks, reviews and other factors. Such multiplicity of the number of overall records and other aspects of relational database functionality could thus limit capabilities of a travel related system for handling, for example, large sets of unstructured data, significant data growth and high rate of concurrent access.